Theatre Resource Manager Interface Specification v. 1.0 Technische Berichte Technical Reports

Since more than 10 years energy efficiency is a well discussed research topic in computer science. Because the immediate consumers of energy are hardware resources, these resources have been subject to optimization in the first place. But hardware is in turn used by software, running on top of it. Software offers the interface to the end-user and thus allows to correlate the utility of end users with energy consumption by hardware resources. To bridge the gap between the users’ needs and energy consumption on the hardware level we propose an energy-aware software architecture. In this paper we focus on a central element of this architecture: the resource manager. 1 The Key to Energy Efficiency: Bridging the Gap between Users and Energy Our research towards an energy-aware software architecture revealed the need for an energy-aware software development process and the energy auto tuning runtime environment (THEATRE) [5]. Our work is part of the project CoolSoftware, which belongs to the CoolSilicon cluster of excellence. The two main concepts in THEATRE are energy and resource managers. Figure 1 depicts the architecture of THEATRE. The three layers of our architecture span from the user to the hardware. The users’ needs are the utility which is gained in turn from energy consumption. But users interact with software, which runs on top of operating systems, virtual machines and so on. We see operating systems and virtual machines as virtual resources. Resources in general are represented by resource managers. Resource managers provide information about their resources and are able to steer them. Energy managers use this information and combine it with their knowledge on valid application component compositions to derive an energy-optimal configuration (component composition and deployment). Each software component has an own energy manager, which provides information about the component and offers functionality to deploy, redeploy or reconfigure the corresponding component. The top-most layer focuses on the users’ needs, which are collected by so-called contextors. Besides collecting the users’ expectations, they also collect 1 http://www.cool-software.org/ 2 http://www.cool-silicon.de/ 2 Sebastian Götz et al. RWゲラ┌ヴIWゲ ふH;ヴS┘;ヴWが OSが VMが ぐぶ Software Components Global Energy Manager Local Energy Manager 1 Local Energy Manager 2 Local Energy Manager 1.2 Local Energy Manager 1.1 Global Resource Manager Local Resource Manager 1 Local Resource Manager 2 Local Resource Manager 2.1 Users E n e rg y E ff ic ie n cy Contextor Fig. 1. The architecture of THEATRE. information for workloads on the system. Such workloads are service requests created by users through the user interface of the software system. Energy managers know what software components require and provide in return. They know about valid system configurations, that is deployments of software components onto resources. After identifying all valid system variants, these variants are assessed in terms of their cost and utility. The variant providing the best combination of cost/utility will be the goal of the reconfiguration, which is forced by the energy manager. Reconfiguration includes the selection of another component implementation, whereas redeployment triggers the migration of a software component from one resource to another. All resource specific information is aggregated up the hierarchy into the global resource manager (GRM). The global resource manager is in turn able to disseminate requests from the global energy manager (GEM). The migration of components might lead to under-utilization of resources. In such a case the global energy manager can request the global resource manager to shut down the under-utilized resource. Before the request can be processed remaining components are migrated to another resource. If all resources are fully utilized, but a further component has to be deployed, the global energy manager will request a new resource from the global resource manager. Hence, the global energy manager renders the decisions, which base on information provided by the resource managers and local energy managers. Figure 2 depicts the autonomic control loop [3], which outlines how THEATRE works and elaborates on the interaction between the global energy and resource THEATRE Resource Manager Interface Specification 3